1. Field
The present disclosure relates generally to wireless devices, and more particularly, to method and apparatus for providing an interface between a UICC and a processor in an access terminal that supports asynchronous command processing by the UICC.
2. Background
Wireless communication systems are widely deployed to provide various types of communication content such as, for example, voice, data, and so on. Typical wireless communication systems may be multiple-access systems capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth and transmit power). Examples of such multiple-access systems may include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and the like. Additionally, the systems can conform to specifications such as third generation partnership project (3GPP), 3GPP long term evolution (LTE), ultra mobile broadband (UMB), evolution data optimized (EV-DO), etc.
Generally, wireless multiple-access communication systems may simultaneously support communication for multiple access terminals, such as, for example, mobile or wireless devices. Each mobile device may communicate with one or more base stations via transmissions on forward and reverse links. The forward link (or downlink) refers to the communication link from base stations to mobile devices, and the reverse link (or uplink) refers to the communication link from mobile devices to base stations. Further, communications between mobile devices and base stations may be established via single-input single-output (SISO) systems, multiple-input single-output (MISO) systems, multiple-input multiple-output (MIMO) systems, and so forth. In addition, mobile devices can communicate with other mobile devices (and/or base stations with other base stations) in peer-to-peer wireless network configurations.
In many access terminals (AT), subscription information is stored in either a nonvolatile (NV) device memory or a removable Universal Interface Circuit Card (UICC) depending on the access technology to which the subscription information pertains. Currently, for example, in certain access terminals, when network service is available on a 1x-RTT/Data Optimized (DO) network technology, network subscription information is stored on and retrieved from the device NV memory. However, in these devices, when service is available on any other access technology—such as GSM, UMTS, or LTE—subscription information is stored on and retrieved from the UICC. The UICC also may be referred to as a smart card or a subscriber identity module or subscriber identification module (SIM) card.
Conventionally, cards, such as a UICC, were used in access terminals to provide network subscription information. However, UICC are now used to handle other tasks. For example, near field communications (NFC) is a set of standards for wireless devices, such as smart phones and the like, to establish radio communication with each other by touching the devices together or bringing the devices into close proximity (e.g., usually no more than a few centimeters). NFC allows wireless devices to perform contactless transactions, data exchange, and simplified setup of more complex communications, such as Wi-Fi. Common examples of NFC applications include applications related to banking and mobile payments. As the market pushes to use the UICC as a preferred Secure Element for such applications, certain issues may arise as between UICC processing of (traditional) telecommunications tasks and (newly-added) non-telecommunications tasks.
Telecommunications applications, which may be processed at a UICC within an access terminal, are time-sensitive and may need ready, and quick, access to the services on the UICC. In contrast, non-telecommunications applications, such as, for example, payment or banking applications, may be highly complex, cryptographic algorithms, which require extremely long times (e.g., even more than one minute) to process a single command.
The interface between the UICC and the terminal (specified in ETSI 102 221, which is publicly available) only allows a single command to be processed by the UICC at a time. As such, an access terminal needs to receive a response to a first command before it may send a second command. In order to process a command that takes a long time (e.g., a complex, non-telecommunications command), the UICC sends NULL bytes (as specified in ETSI 102 221) in order to inform the access terminal that it is still processing the command and to request the access terminal continue to wait for the response.
As a result of the UICC processing such complex, non-telecommunications commands that take a very long time to process, the UICC may essentially be blocked, or unavailable, to the access terminal for receiving, and processing, any additional commands until the non-telecommunications command is finished processing. Because of the time-sensitive nature of telecommunications-related commands, such unavailability of the UICC may result in a user being unable to initiate a voice call, send a text message, authenticate to a network, utilize high-level operating system (HLOS) applications (often referred to as “apps”) or perform any number of other actions. This situation is untenable and would be unacceptable to a user of the wireless device.
As such, improvements in processing commands from an access terminal by a UICC are desired.